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(54) Method and apparatus for retransmitting video data frames with priority levels 


(57) The invention relates to a method and appara- 
tus for transmitting and receiving video data arranged 
in data frames forming a data stream. Each frame has 
assigned a priority level. Once a data frame has been 
transmitted through an unreliable channel and has not 
been received at the receiver, the priority level of the 
missing data frame is compared with a priority threshold 
value, and is then retransmitted if its priority level is 
greater than the priority threshold value. The retrans- 


mission decision is performed either at the transmitting 
or at the receiving side. According to a preferred em- 
bodiment, the priority level of any data frame to be trans- 
mitted is compared with the threshold value. The priority 
decision may involve the calculation of the priority 
threshold value based on a measurement of the availa- 
ble channel bandwidths and eventually on the bit rate of 
previously sent frames. The retransmission decision fur- 
ther may include an estimation of the arrival time of the 
data frame to be retransmitted. 
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Description 


[0001] The present invention relates to a data trans- 
mission method and apparatus and more particularly to 
video streaming applications. 

[0002] In video and multimedia communications 
many applications exist in which video streams are de- 
livered over non-reliable channels. Examples of such 
applications include personal computers, TV apparatus 
and computer cards, MPEG decoders and boards, mul- 
timedia transceiver systems and set-top receiver units, 
DVD devices, video recorders and CCD cameras, video 
signal equipment, frame grabbers and image capture 
boards industrial and medical imaging products, video 
printers and projectors, or the like. It will therefore be 
appreciated that many kinds of video streaming appli- 
cations in the consumer market as well as professional 
applications exist both in software and hardware. 
[0003] A video stream consists of a flow of bil-packets 
called frames that contain information about the video 
picture itself as well as some meta information such as 
time stamps. The frames contain the video information 
in different formats depending on the video compres- 
sion. Some of these frames can be used independently, 
so-called intra-coded frames or l-frames, while others 
depend on the preceding frame, so-called predictive- 
coded frames or P-frames: 

[0004] FIG. 1 illustrates a conventional video stream- 
ing system. Video server 110 transmits video data 
through channel 150 to video client 160. For this pur- 
pose, the video server 1 1 0 includes a transmitter buffer 
unit 130 which receives video frames with nearly no de- 
lay from video source application 120. The bit rate of 
this internal transmission is only limited by the video 
source application's bit rate. In the transmitter buffer unit 
130 the frames first undergo segmentation, i.e. splitting 
data packets by lower layer protocols into smaller seg- 
ments with the number of segments depending on the 
length of the packet, which is variable and may for in- 
stance amount to 200 or 2,000 byte. This segmentation 
determines one part of the transmission time for the re- 
spective packet. 

[0005] Once the frames have undergone segmenta- 
tion the segments are sent on the channel in defined 
time slots according to the available channel bit rate. In 
unreliable channels 150 bit errors occur and the availa- 
ble channel bit rate varies in time, if the channel is 
shared by multiple users. This leads to a significant and 
variable propagation delay. 

[0006] Access to the channel 150 is given to the trans- 
mitter buffer unit 130 by channel access controller 140. 
As the bit rate of channel 150 is lower than the bit rate 
of the video stream received from video source applica- 
tion 120, those segments which could not be sent are 
buffered by the transmitter buffer unit 130 in a first-in- 
first-out (FIFO) queuing discipline. The transmission 
buffer unit and the channel access controller are isolat- 
ed entities and totally independent from the video appli- 


cation. Hence, the video source application 120 does 
not receive any feedback about the status of the frames 
as to whether they are already sent or whether they are 
buffered. All data will be sent by the transmitter buffer 
5 unit 1 30 in the order it arrived. 

[0007] The segments or PDUs (protocol data units) 
transmitted by the video server 110 are received by the 
video client 1 60 in a receiver buffer unit 1 70. The receiv- 
er buffer unit 170 includes a buffer for storing the re- 
w ceived data, and also reassembles the frames from the 
segments. The video frames are then sent to video dis- 
play application 180 which might for example likewise 
be a storage device or the like. 

[0008] Two main problems occur in video transmis- 
15 sions over unreliable links. The first problem is that be- 
cause of changes in the channel condition, the bit error 
rate may increase such that packet loss occurs. Since 
compressed video streams are extremely susceptible 
for packet loss, the video quality is decreased dramali- 
20 cally. The second problem may arise from the variable 
and sometimes very high delay of the video data which 
might lead to situations in which the delay requirements 
for the transmission are no longer fulfilled and the video 
performance again is decreased dramatically. 
25 [0009] For reducing the packet loss several mecha- 
nisms exist in the prior art. One of these mechanisms is 
a method called automatic repeat request (ARQ), ac- 
cording to which the loss of a packet is detected in the 
receiver and the transmitter is informed accordingly. The 
30 transmitter then automatically repeats the transmission 
of the lost packet so that missing video frames are re- 
transmitted. However, not all of the lost packets can be 
retransmitted because of the delay requirements and/or 
limited bandwidth of the transport channel. Moreover, 
35 such prior art systems lead to a higher delay which might 
not be tolerable in any case. 

[0010] A prior art system for overcoming the second 
problem, i.e. the occurrence of a variable and some- 
times very high channel delay, is called Real-Time 
40 Transport Protocol (RTP). To control the display times 
and cope with the real time requirements, this protocol 
adds some information to the video frames such as time 
stamps and sequence numbers, encapsulated in RTP 
packets. This information is used to send the video 
45 frames at the right time and in correct sequence. The 
receiver may perform some measurements, e.g. of de- 
lay jitter, and may signal the results to the source by 
means of the RTP control protocol (RTCP). 
[0011] One approach to deal with both problems, i.e. 
so packet loss and channel delay, is to improve the RTP 
technique such that only the l-frames are retransmitted 
and that before sending any frame a judgement is made 
whether the retransmitted l-frame would still arrive in 
time. Such integration of retransmission mechanisms in 
55 the RTP technique can be for instance done by using 
multi-purpose acknowledgement (MACK) packets 
which can be extended by protocol-specific fields. By 
restricting retransmission to l-frames and introducing a 
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timer-based judgement for deciding whether to send a 
frame or to discard it, both problems are addressed, 
leading to an increased video quality because more 
frames can be displayed. The delay is kept in a reason- 
able range by discarding "old" frames, i.e. frames that 
would be received after expiration of their display time. 
[0012] Such systems however, would have a signifi- 
cant degree of inadaptability because the retransmis- 
sions are limited to the l-frames even when enough free 
bandwidth is available to retransmit all frames. In certain 
channel conditions many correctly received P-frames 
are discarded at the video client, because the preceding 
P-frame was not received correctly. 
[001 3] Moreover, such techniques perform poorly be- 
cause frames are sent which should have been discard- 
ed and vice versa. This is because the judgement 
whether to send a frame or to discard it is based on a 
fixed estimated transmission time which is set at the be- 
ginning of the transmission for every packet and is the 
same for all the packets, being independent of the chan- 
nel status and the respective packet length. The fixed 
estimated transmission time is needed to calculate the 
time at which the frame would be received. 
[001 4] A similar method for selectively retransmitting 
missing data packets of a data stream is disclosed in 
US 5,918,002. Retransmission is prioritized based on 
data types of the data packets. For example, since par- 
ent l-frames are needed to render dependent child P- 
frames, data packets which include l-frames are as- 
signed higher priority for transmission and/or retrans- 
mission over data packets which include only P-frames. 
Moreover, the sequence of retransmission requests is 
priority-dependent. 

[0015] Another technique which is concerned with re- 
suming playback taking into consideration the different 
importance of I- and P-frames is disclosed in US 
5,784,527. 

[0016] In US 5,768,527 it is disclosed that upon de- 
tection of a lost packet the client device requests a 
number of multiple copies of the lost packet, with said 
number depending on the importance of the lost frame. 
[001 7] The mentioned prior art, however, leads to the 
above-described disadvantages when transmitting vid- 
eo data through an unreliable channel, that is, a reduced 
video stream quality due to a restricted capacity and be- 
cause the prior art techniques may use the channel 
bandwidth inefficiently. 

[0018] It is therefore the object of the invention to pro- 
vide a method and an apparatus for receiving and trans- 
mitting video data forming a data stream leading to in- 
creased video quality when being operated on an unre- 
liable channel. 

[001 9] This object is solved according to the invention 
as defined in the independent claims. 
[0020] According to the invention, retransmission of 
lost data frames is performed based on a comparison 
of the priority level of the frame .with a threshold value. 
This goes beyond the teaching of the prior art in that not 


4 

only l-frames may be retransmitted. Consequently, by 
providing a priority threshold, the invention allows for 
adapting the transmission capability to a number of fac- 
tors including actual channel properties. According to a 
5 preferred embodiment, the priority level of any data 
frame to be transmitted is compared with the threshold 
value. With the invention it is therefore possible to in- 
crease the video quality even when the priority threshold 
value is fixed. 

10 [0021] The invention is therefore in particular advan- 
tageous when applied to compressed video (e.g. 
MPEG-4) streaming transmissions over unreliable (e.g. 
wireless) links. 

[0022] Comparing the priority level of the missing data 
'5 frame with a threshold value and transmitting the frame 
on the basis of the comparison result may advanta- 
geously be performed at the server side as well as the 
client side. If the decision is made in the client there is 
no need to send retransmission requests in those cases 
20 where the decision is denied, but the priority of the actual 
frame has to be transmitted. This leads to a most effi- 
cient use of the channel bandwidth in uplink direction, 
however the transmitted data in downlink direction is 
slightly increased. On the other hand, when the trans- 
25 mission decision is done on the server side, the server 
receives feedback information which might be valuable. 
Moreover, the client would advantageously be of a more 
inexpensive constructional design. 
[0023] Preferred embodiments of the invention are 
30 defined in the dependent claims. 

[0024] If the transmission decision is done on the 
server side, it is advantageous when the client's retrans- 
mission requests include the reception times and frame 
lengths of two preceding data frames. Using this infor- 
ms mation, the server would be in the position to most effi- 
ciently update his knowledge about the channel state, 
keep the delay requirements and use the channel band- 
widths. 

[0025] Moreover, since in contrast to the prior art sys- 

40 terns the transmission time of the packets is measured 
during the video streaming, they are no longer assumed 
to be the same for all packets. Changes in the transmis- 
sion time may therefore lead to a dynamic adaptation of 
the video stream quality to changing chan nel conditions. 

45 [0026] Independently of whether the transmission de- 
cision is performed on the transmitter or on the receiver 
side, priority levels are assigned to the data frames pref- 
erably based on the logical depth of multidependency. 
By this measure it is incidentally taken into consideration 

50 that those frames which are independent (l-frames) are 
the most important frames, whereas dependent frames 
are less important. Moreover, in contrast to the prior art, 
even the group of dependent frames is divided into more 
important and less important frames. This allows for fine 

55 tuning the retransmission behaviour to an extent which 
is not known from the prior art. 

[0027] Another advantage of the present invention is 
that the improvement of the video quality may be in- 
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creased by making the transmission decision dynami- 
cally. This is done according to a preferred embodiment 
of the invention by calculating the priority threshold val- 
ue based on the measured available channel band- 
width. Additionally, the measured sending bit rate may 
be used. Consequently, the compensation for missing 
packets may be improved once again. 
[0028] Furthermore, the invention may be combined 
with the requirement that a lost frame is retransmitted 
only when it is expectable that the retransmitted frame 
will still arrive in time. In particular in cases where the 
channel bandwidth is shared between several users or 
applications it is very important to transmit as little data 
as possible. This is true in particular because the user 
might pay tor the used bandwidth, i.e. the transmitted 
bits. If there are video packets retransmitted which 
would not reach the receiver in time because of the high 
utilization of the channel, bandwidth is wasted. This 
bandwidth could be used either for the retransmission 
of frames which have a higher priority or by other users 
or applications. 

[0029] The invention will now be described in more 
detail with reference to the accompanying drawings, in 
which: 

FIG. 1 is a prior art video streaming system; 
FIG. 2 is a video streaming system according to a 
preferred embodiment of the invention; 
FIG. 3 is a graph illustrating the priority assignment 
to the frames according to the preferred embodi- 
ment of the invention; 

FIG. 4 is a flow chart illustrating the process of send- 
ing a video stream; 

FIG. 5 is a flow chart illustrating the retransmission 
decision in the process of sending a video stream 
as depicted in FIG. 4; 

FIG. 6 is a flow chart illustrating a first example of 
the priority decision being part of the retransmission 
decision depicted in FIG. 5; 

FIG. 7 is a flow chart illustrating a second example 
of the priority decision; 

FIG. 8 is a flow chart illustrating a third example of 
the priority decision; and 

FIG. 9 is a flow chart illustrating the process of re- 
ceiving a video stream. 

[0030] Referring now to FIG. 2, the video server 110 
includes a video source application 120, a transmission 
buffer unit 130 and a channel access controller 140 
which function substantially as described in the context 
of the prior art video streaming system of FIG. 1 . Simi- 
larly, the video client 160 includes a receiver buffer unit 
170 and a video display application 180. Data are sent 
from the video server 1 1 0 to the video client 1 60 th rough 
channel 150, 

[0031 ] The video client 1 60 further comprises loss de- 
tection unit 240, which is connected to the receiver buff- 
er unit 1 70. Once the loss detection unit 240 detects that 


a frame is missing : it generates a retransmission re- 
quest which preferably includes the reception times and 
frame lengths of two preceding data frames. For this 
purpose, the loss detection unit 240 stores during nor- 

5 mal operation the time stamp and length of the most re- 
cent two packets. Once the retransmission request has 
been generated, which might be a non-acknowledge- 
ment (NACK) or a multi-purpose acknowledgement 
(MACK) packet, the request undergoes segmentation 

10 by transmitter buffer unit 250 and is sent under control 
of channel access controller 260 through channel 150 
to video server 110. 

[0032] Inthe VideoServer 110, receiver buffer unit 230 
receives the data and reassembles the request. The re- 
15 quest is then forwarded to control unit 210, and to the 
retransmission buffer 220. The retransmission buffer, 
buffers the I- and P-frames sent from the video source 
application 120 to the transmitter buffer unit 130 for re- 
transmission purposes. 
20 [0033] The control unit 210, upon receiving the time 
and length information of the two most recent packets, 
updates the priority thresholds. When receiving video 
frames from the video source application 120 or the re- 
transmission buffer 220, it performs the transmission 
25 decision on the basis of the priority levels assigned to 
the data frames. The assignment of priorities to frames 
is illustrated in more detail in FIG. 3. 
[0034] As apparent therefrom, according to the 
. present invention l-frames have been given the highest 
30 priority since an l-frame can be displayed by video dis- 
play application 180 independently from other frames. 
The first P-frame which closely follows the l-frame de- 
pends only on the preceding l-frame. The second P- 
frame depends on the first P-frame, and since the first 
35 P-frame depends on the l-frame, the second P-frame is 
two-fold dependent and therefore less important than 
the first P-frame. This scheme may be adopted for the 
following P-frames so that P-frames with higher depth 
of muttidependency, i.e. later P-frames, are more unim- 
40 portant and are therefore given the lower priority levels. 
In the embodiment of FIG. 3 the priority is set to Mn for 
the n-th P-frame. It will however be appreciated by those 
of ordinary skill in the art that another functional depend- 
ency may be chosen. 
45 [0035] Referring nowto FIG. 4, the process of sending 
a video stream includes the step of receiving a video 
frame from the video source application 120 (step 41 0). 
Then it is checked in step S420 whether a retransmis- 
sion request has been received. If no retransmission re- 
50 quest has been received, the process proceeds with 
step S440, otherwise the information from the retrans- 
mission request is used to update the channel estima- 
tion first (step S430). In step S440 the transmission de- 
cision is made, which will be described in detail in the 
55 next figures. 

[0036] The transmission time of a frame consists of 
two parts. One part is independent of the length of the 
frame, whereas the other part is length dependent. The 
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frame-length independent time consists mainly of the 
network delay, i.e. the propagation delay, and the buff- 
ering delay due to congestion. In contrast, the frame- 
length dependent delay is determined by the segmen- 
tation and the available bandwidth. The following equa- 
tion describes the transmission delay of frame i: 

where D, is the transmission delay, /, is the frame length 
in bits, /., is the frame-length independent time, and t 2 is 
the frame-length dependent time per bit. 
[0037] Assuming that the times ^ and t 2 are nearly 
constant between two packet arrivals, the equation can 
be resolved when the transmission delays D 1 and D 2 of 
two preceding frames have been previously measured: 

_ D 2 l,-D,l 2 

'1 '2 

D, - D 2 

1 '2 

[0038] It is consequently possible to calculate the 
transmission delay of a missing frame from the times f t 
and t 2 which are evaluated on the basis of the transmis- 
sion delays of two preceding frames. For this purpose, 
loss detection unit 240 stores the reception times and 
packet lengths of the most recent frames. If an error oc- 
curs, these values and the values of the missing or er- 
roneously received frame are transmitted to the video 
server 110. This can be done either by attaching a Re- 
ceiver Report to the NACK packet or by using a MACK 
packet. The overhead added by supplementing the 
NACK or MACK packet with such additional information 
is negligibly small. 

[0039] If it is decided in step S440 that the frame 
should be discarded, the process proceeds with step 
S460. If the frame should be sent to the transmission 
buffer 1 30, step S450 is executed. Then the sending bit 
rate is updated in step S470 and the control unit 21 0 will 
wait for the next frame to receive from the video source 
application 120 or the retransmission buffer 220 (step 
S410). 

[0040] The transmission decision of step S440 will 
now be explained in more detail with reference to FIG. 
5. Before comparing the priority with a threshold value, 
a mechanism is introduced to decide whether the frame 
should be sent or discarded according to an estimated 
arrival time since it is not necessary to send frames that 
are already too late. For that purpose, the arrival time of 
the frame is estimated, i.e. the transmission delay is cal- 
culated in step S510. 

[0041] If it is then determined in step S520 that the 
estimated arrival time is later than the desired time to 


display the video frame, the frame will be discarded in- 
stead of being transmitted. Otherwise, control unit 210 
evaluates the priority of the missing frame as will be now 
explained in more detail. 

5 [0042] Referring now to FIG. 6, control unit 210 first 
obtains the priority level of the frame in step S610, and 
then accesses the fixed threshold level in step S620. 
There should be two different priority levels. One for 
frames transmitted for the first time (possibly all frames 

10 are transmitted for the first time) and for the retransmis- 
sions. The fixed threshold levels have been defined at 
the time of transmission set-up according to the channel 
condition and video bit rate at that time, it is then decided 
in step S630 whether the priority level of the frame ex- 

15 ceeds the priority threshold level. Only if this is the case, 
the frame is transmitted. Otherwise, it is decided to dis- 
card the frame. 

[0043] White this advantageously involves a minimum 
overhead and implementation effort only, it may be im- 
20 proved as apparent from FIG. 7. The process illustrated 
in FIG. 7 differs from that of FIG. 6 mainly in that not a 
fixed threshold level is used but that the priority thresh- 
old is calculated based on the measured available chan- 
nel bandwidth (steps S710, S720). This scheme is 
25 based on the idea that, if only a small bandwidth of the 
channel is available, it might be better to send frames 
with higher priority only. 

[0044] Since the available bandwidth is the reciprocal 
of t 2 , the measurement of the available channel band- 
30 width can make use of the above-mentioned measure- 
ment of transmission delays: 

B ch= T • 
35 f z 

[0045] The available channel bandwidth B ch meas- 
ured in step S710 is then used in step S720 to calculate 
the priority threshold value P th according to the following 
40 equation: 


where B v is the bandwidth needed for the video trans- 
mission if no retransmissions are performed at all, and 
k is a factor to adapt the mechanism to the system and 
the bit error rate which is assumed to be fixed for the 
transmission. There should be two different k-factors. 
One for transmissions for the first time (possibly all 
frames should be transmitted for the first time) and one 
for the retransmissions. 

[0046] Yet another improvement of the priority deci- 
sion process may be achieved as illustrated in FIG. 8 by 
additionally measuring the bit rate of the sent frames in 
step S810. This improvement is based on the discovery 
that with bad channel conditions, i.e. high bit error rates, 
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the number of frames to be retransmitted increases. It 
is therefore advantageous to monitor the amount of data 
that was sent to ensure that enough channel bandwidth 
is reserved to transmit at least the important frames. To 
estimate the bit rate of sent frames, an average bit rate 
over a number of preceding frames which were sent is 
calculated according to the following equation: 


p 


B. = 


10 


15 


[0047] In this equation, B s is the bit rate of the sent 
frames p and q denote the oldest and the most recently 
sent frames, and /,, t q and t p are the previously stored 
lengths in bits and transmission times of the respective 
frames. 

[0048] Using the bit rate B s of sent frames measured 
in step S81 0, the priority threshold value P th is then cal- 
culated in step S820, similarly to the calculation de- 
scribed above: 


[0049] While the transmission mechanisms on the ba- 
sis of a priority decision have been described together 
with an arrival time estimation, it will be appreciated by 
those of ordinary skill in the art that the mechanisms may 
likewise be used independently from each other. 
[0050] FIG. 9 illustrates the process of receiving a vid- 
eo stream in video client 160. Upon detecting in step 
S920 that a video frame is missing, a retransmission re- 
quest is generated and transmitted in steps S930 and 
S940 as described above. While in the preferred em- 
bodiment, the retransmission decision is performed by 
control unit 21 0 of video server 1 1 0 , it will be appreciated 
by the skilled person that the decision whether a missing 
frame is to be retransmitted may likewise be performed 
at the receiver. For this purpose, the video client 160 
would comprise a control unit (not shown) f orcalculating 
the priority threshold value and comparing the priority 
level of the missing frame with the threshold value. Only 
in case it is decided to retransmit the missing frame, a 
retransmission request would be sent from video client 
160 to the video server 110. The retransmission deci- 
sion step S440, illustrated in FIGs. 5 to 8, would then be 
incorporated into the process of receiving the video 
stream in FIG. 9 prior to the step S930 of generating a 
retransmission request. 


Claims 

1 . Method for transmitting video data from a server to 
a client, said data being arranged in data frames 
forming a data stream, each frame having assigned 
a priority level, the method comprising the steps of: 

receiving (S420) at the server a client's retrans- 
mission request for a data frame; 

comparing (S630, S730, S830) the priority level 
of the requested data frame with a priority 
threshold value (P th ); and 

retransmitting (S450) the requested data frame 
if the priority level is greater than said priority 
threshold value. 


2. The method according to claim 1 , further compris- 
20 ing the step of comparing the priority level of any 

data frame to be transmitted with said priority 
threshold value. 

3. The method according to claim 1 or 2, wherein the 
25 retransmission request includes the reception times 

and frame lengths of at least two preceding data 
frames. 

4. Method for receiving video data from a server, said 
30 data being arranged in data frames forming a data 

stream, each frame having assigned a priority level, 
the method comprising the steps of: 

detecting (S920) that a data frame is missing; 

comparing (S630, S730, S830) the priority level 
of the missing data frame with a priority thresh- 
old value (P th ); and 

40 sending (S940) a retransmission request for 

the missing data frame to the server. 

5. The method according to one of claims 1 to 4, 
wherein the frames having assigned a priority level 

45 include P-frames. 

6. The method according to one of claims 1 to 5, 
wherein the assignment of priority levels to frames 
is performed according to the logical depth of the 

so multidependency of the respective frame. 

7. The method according to one of claims 1 to 6, 
wherein the step of comparing includes the steps of 
measuring (S710)the available channel bandwidth 

55 (B ch ) and calculating (S720, S820) said priority 
threshold value based on the measured bandwidth. 

8. The method according to claim 7, wherein the step 


35 
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of comparing further includes the step of measuring 
(S810) the bit rate (B s ) of previously sent frames, 
wherein said priority threshold value is calculated 
based on the measured bandwidth and the meas- 
ured bit rate. 5 

9. The method according to one of claims 1 to 8, fur- 
ther comprising the step of estimating the data 
frame arrival time and comparing the estimated ar- 
rival time with the desired arrival time for suppress- 10 
ing transmission if the estimated arrival time is not 
before the desired arrival time. 

10. Apparatus for transmitting video data to a client, 
said data being arranged in data frames forming a 1$ 
data stream, each frame having assigned a priority 
level, the apparatus comprising: 

receiver means (230) for receiving a retrans- 
mission request from the client for a data frame; 20 

a controller (21 0) for comparing the priority lev- 
el of the requested data frame with a priority 
threshold value; and 

25 

transmitter means (1 30, 220) for retransmitting 
the requested data frame if the priority level is 
greater than said priority threshold value. 

11. Apparatus for receiving video data from a server, 30 
said data being arranged in data frames forming a 
data stream, each frame having assigned a priority 
level, the apparatus comprising: 

detection means (240) for detecting that a data 35 
frame is missing; 

a controller for comparing the priority level of 
the missing data frame with a priority threshold 
value; and 4° 

transmitter means (250) for sending a retrans- 
mission request for the missing data frame to 
the server. 

45 

12. The apparatus according to claim 10 or 11, ar- 
ranged for performing the method according to one 
of claims 1 to 9. 
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